1. Field of the Invention
The present invention relates generally to database systems and object systems, and particularly to managing persistent objects in a distributed object system using a database system.
2. Description of the Related Art
Object-oriented programming has allowed programmers to develop software without the constraints of particular languages, tools, operating systems, address spaces, networks, compilers or applications. This is possible because object-oriented programming languages allow computing systems executing a particular application to be viewed as a collection of individual objects that achieve the desired application function by exchanging messages among themselves.
In distributed computing environments it is desirable to access remote objects across computer networks. Standards are evolving for creating infrastructures in object-oriented programming languages which will allow a component, consisting of selected distributed objects, to exist on any network and communicate with other components, whether it be across desk tops or whole enterprises. One of the more pervasive standards is the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG).
In the CORBA specification a client is given the ability to access an object through an object reference to that object. The object reference is the information needed to specify an object to an Object Request Broker (ORB). Object references not only allow objects to be identified in a request from a client to an ORB, but also can be used to carry metastate for persistent objects. A persistent object is one that can continue to exist even if a machine is removed or disconnected from the network. The metastate for a persistent object is the critical data needed to restore the persistent object when it does not exist in the memory of the ORB""s process.
Another widely used standard for the management of objects in a distributed computing environment is Java Remote Method Invocation (RMI). Java RMI is a mechanism that allows one to invoke a method on an object that exists in another address space. The other address space could be on the same machine or on a different machine. While CORBA is a language-independent standard, Java RMI provides for remote communication only between programs written in the Java programming language. There are three processes that participate in supporting remote method invocation with Java RMI. The Client is the process that is invoking a method on a remote object. The Server is the process that owns the remoter object, which exists as an ordinary object in the address space of the server process. The Object Registry is a name server that relates objects with names. Objects are registered with the Object Registry. Once an object has been registered, one can use the Object Registry to obtain access to a remote object using the name of the object.
However, CORBA, Java RMI and other distributed object management systems do not provide a means by which the objects themselves, or their persistent states are managed in a coordinated and uniform manner. In particular, the state of persistent objects, referred to as object instances, change dynamically based on method invocations on these objects. There are complex systems that enable instantiation of these objects on demand (called Activation in Java RMI), to be able to handle large numbers of objects, only some of which could be active at a given time. Persistence is achieved explicitly by writing out the object state to relational databases, or to file systems. However, the management of the object identities, their persistent state and the programs that encapsulate their behavior has not been performed in a generally uniform way in the past.
As a result of their limited management capabilities, distributed object systems such as Java RMI are not always able to manage the object system with integrity and robustness. For example, the persistence and transactional semantics of the object system may not be clearly defined. Also, access control cannot always be adequately enforced. Furthermore, such systems do not provide automated and coordinated backup and recovery of the state of the object system (and not just individual objects). This limits the complexity of transactions that can occur within the object system.
The limitations on the management capabilities of object systems are due, in part, to the fact that objects generally exist as files within an object system, which operates as a type of file system. File systems in general perform various functions for users. These include: accessing data stored in files, managing files, managing direct access storage space where files are kept, and guaranteeing the integrity of files. File systems however, are not aware of the internal structure of the file and, therefore, cannot provide access to them in response to requests that presume knowledge of such structure. For example, if a file system stores movies, the system would be able to locate and retrieve a file in which a digitized version of a particular title is stored, but would not be able to respond to a request to return the titles of all movies made by a particular director.
A database system however, can provide such searching capability. Ordinarily, in a database features of an object (such as a digitized image of a movie) are extracted from the file, formatted according to the database system structure, and then used by the database system to support the search of stored objects based on the extracted features. Database systems however, are generally set up to store, access, and retrieve only relatively short objects, such as records. The raw content of a large object captured in a file system may be so vast as to be impractical to structure for a database request.
Conventional distributed object systems exist as files on file servers that have constraints that are different from a database system. They are not necessarily database-aware since they do not invoke database commands. Hence, the full management power of database systems cannot currently be used to manage such object systems.
Technology available from IBM (DB2 Universal Database) and Oracle allows management of files as though they are logically part of the database system (as Binary Large Objects or BLOBS). Some database systems provide object views and method invocations in the database by enabling flavors of database query languages that support method invocations to objects within the database. Many systems enable object views over database schema to enable external applications to treat the data within the database as objects.
However, there is a need for a technique that provides the persistence and management capabilities of database systems in the management of distributed objects residing outside the database system. There is also a need for a system to provide automated backup and recovery of the state of distributed object systems. There is also a need for a system to provide clearly defined persistence and transactional semantics to permit more complex transactions to be performed by object systems.
A system and method for managing a distributed object system containing persistent objects. The invention allows the management capabilities of a database management system to be utilized in the management of a distributed object system. In one aspect of the invention, a method is provided for managing a distributed object system having objects stored in object system files, wherein the distributed object system is connected to a client application. A connection is created between a database system and the distributed object system for exchange of information between the database system and the distributed object system files. Control information is provided on the connection between the database system and the distributed object system files, which causes the distributed object system to control processing of the objects in the distributed object system files according to constraints established at the database system.
In another aspect of the invention a system is provided for managing a distributed object system that includes a server object, wherein objects are stored in files in the distributed object system. The system includes a database system, a client object, and a connection between the database system and the distributed object system. This connection allows the exchange of information between the database system and the distributed object system files. Also, control information is provided on the connection between the database system and the distributed object system files, which causes the distributed object system to control processing of the objects in the distributed object system files according to constraints established at the database system.